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EVALUATION 


The  work  performed  under  this  contract  clearly  demonstrates  the 

- ( >' 

feasibility  and  outlines  the  usefulness  of  a Reconfigurable  Computer 
System  Design  Facility  (RCSDF)  in  developing  and  evaluating  new  and 
unique  computer  architectures  to  solve  Air  Force  processing  requirements. 
This  effort  represents  the  successful  completion  of  one  aspect  of 
RADC’s  comprehensive  investigation  into  the  Total  System  Design  (TSD) 
methodology  aimed  at  providing  more  effective  development  tools  for 
the  system  designer  (TPO-5,  FY-77,  78). 

The  results  of  this  effort  will  enable  RADC  to  proceed  deeper  into 
investigations  on  TSD  and  begin  to  develop  various  elements  of  the 
RCSDF. 

*77^1  Ci 

MICHAEL  A.  TROUTMAN,  2Lt,  USAF 
Project  Engineer 
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1 . INTRODUCTION 


The  costs  of  developing  and  maintaining  software  for  modern 
military  systems  are  increasing  at  alarming  rates . Awareness  of 
this  situation  has  motivated  an  exploration  of  the  causes  of  this 
cost  increase  and  ways  to  reduce  it.  One  alternative  that  shows 
significant  promise  is  total  system  design,  which  provides  the 
necessary  tools,  evaluation  techniques,  and  methods  (i.e.,  a 
Total  System  Design  Facility  - TSDF)  needed  for  extensive  mon- 
itoring of  the  total  development  process.  The  total  system 
design  concept  envisions  a disciplined  system  design  environment 
that  allows  overall  system  designs  and  alternatives  to  be 
quickly  and  easily  evaluated  minimizing  actual  development  and 
life-cycle  costs  for  new  systems. 

1 . 1 Pro j ect  Scope 

The  objective  of  the  initial  Reconf igurable  Computer  System 
Design  Facility  (RCSDF)  design  study  was  the  preparation  of  a 
development  plan  describing  the  necessary  studies  and  develop- 
ment tasks  that  would  achieve  the  required  facility  capabilities. 

The  initial  RCSDF  design  study  was  organized  into  three  major 
tasks: 

Task  1:  Evaluation  and  Definition  of  RCSDF  Capabilities, 
Philosophy,  Procedures 

Task  2:  Performance  of  RCSDF  Technical  Baseline  Develop- 
ment Studies 

Task  3;  Preparation  of  a RCSDF  Development  Plan 

The  three  tasks  of  the  initial  RCSDF  design  study  led  to  a 
development  plan  for  a demonstration  of  the  TSDF  concept  with 
available  hardware  and  technology  (the  RCSDF)  during  the  1980s. 
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1 . 2 Recommendations 


In  general,  the  Sperry  Univac  study  team  has  found  RADC's  con- 
cept of  total  system  design  utilizing  the  reconfigurable  computer 
system  design  facility  for  system  evaluation  to  be  a viable 
method  with  significant  potential  for  reducing  future  system 
hardware  and  software  costs.  The  Sperry  Univac  study  team 
recommends,  via  the  proposed  development  plan,  that  RADC  emphasize 
the  following  tasks  for  RCSDF  development  in  the  near  future  (12 
to  18  months) : 

Emulation  System  Architecture  Study  (Vol.  II,  para.  4.3.1) 
Emulation  Control  Structure  Study  (Vol.  II,  para.  4.3.2) 
Emulation  Analysis  Structure  Study  (Vol.  II,  para.  4.3.3) 

The  Sperry  Univac  study  team  further  recommends  that  tht!  case 
study  tasks  identified  in  the  proposed  development  plan  (Vol.  II, 
Section  4)  , be  implemented  to  provide  RADC  a demonstration  of 
the  total  system  design  concept. 

1.3  Document  Scope 

The  technical  information  developed  during  the  initial  RCSDF 
design  study  is  contained  in  the  following  documents: 

Volume  I RCSDF  Initial  Design  Study-Final  Report 
Technical  Summary 

Volume  II  RCSDF  Initial  Design  Study-Final  Report 
Technical  Results 
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2.  The  Total  System  Design  Facility 


The  Total  System  Design  Concept  (TSDC)  is  a concept  formulated 
by  the  Rome  Air  Development  Center  (RADC)  to  aid  the  development 
of  more  cost-effective  Air  Force  digital  system  designs.  The 
TSDC  emphasizes  design  process  automation  resulting  from  data 
processing  research.  The  future  Total  System  Design  Facility 
(TSDF)  is  general  purpose  in  nature  providing  the  necessary  aids 
to  support  the  development  of  realistic  specifications  from 
which  cost  performance  effective  systems  can  be  procured.  The 
TSDF  as  conceived  would  provide: 

1)  in-depth,  on-line  performance  analysis  of 
developing  system  architecture  alternatives 

2)  shortened  conception-to-specif ication  times 

3)  system  design  with  high  level  languages 

4)  the  means  to  quickly  incorporate  technological 
advances  in  data  processing  hardware  into  the 
Air  Force  inventory  thereby  assuring  longer, 
more  useful  system  life 

5)  the  means  to  upgrade  Air  Force  capabilities  to  use 
advanced  data  processing  techniques 

2.1  TSDF  Summary 

Figure  2-1  illustrates  a TSDF  consisting  of  five  subsystems. 

In  brief,  the  organized  ideas  for  a deployable  application 
system  enter  into  system  design  by  means  of  the  thought  processes 
of  man  (human  subsystem) . These  thoughts  are  formalized  and 
submitted  to  tools  (hosting  subsystem)  which  aid  and  simplify 
the  decision-making  process.  Decisions  for  functional  imple- 
mentation by  means  of  hardware  or  software  must  be  made  here. 

When  the  implementation  decision  is  made  specifications  can  be 
submitted  by  the  hosting  subsystem  to  normal  industrial  process 
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control  procedures  (system  integration  subsystem) . The  inte- 
gration subsystem  has  been  depicted  with  dotted  lines  to  indi- 
cate that  this  procedure  is  rapidly  moving  from  a process  re- 
quiring human  intervention  to  one  which  can  be  totally  auto- 
mated, thus  further  reducing  hardware  costs. 


Figure  2.1.  A TSDF 

When  the  human  subsystem  together  with  the  hosting  subsystem 
has  determined  the  means  for  implementation,  a critical  phase 
(evaluation)  of  system  design  is  entered.  Thus  a Reconfigurable 
Subsystem  (RS)  usable  for  evaluation  with  controlled  performance 
measurement  (known  performance  deficiencies)  becomes  mandatory. 

After  evaluating  the  TSDC  and  its  implementation,  the  TSDF,  the 
following  conclusions  were  reached: 

o The  TSDC,  as  presented,  has  a wider  applicability  than 
just  the  development  of  hardware  and  software  design 
specifications.  Its  scope  could  extend  into  require- 
ments formulation  phases,  system  tuning,  and  software 
development . 

o Automated  development  tools  should  be  provided  for 
users  to  guide  the  direction  of  their  development. 
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Equal  emphasis  should  be  placed  upon  specifying  and 
implementing  the  digital  processing  environment  under 
which  the  emulated/simulated  system  is  being  tested. 

Hosting  of  the  evaluation  process  (system  emulation/ 
simulation,  environment,  etc.)  is  an  essential  in- 
gredient of  the  TSDF.  The  anticipated  complexity  of 
testing  and  the  possible  multiplicity  of  users  point 
to  the  need  to  centralize  system  generation  using  a 
data  base. 

The  definition  of  a High  Level  Performance  Measurement 
Language  (HLPML)  ought  to  be  pursued  as  a part  of  the 
TSDF  to  provide  users  with  a capability  comparable  to 
that  in  the  HOL,  HLHDL. 
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3.  RCSDF  Summary 


The  RCSDF  operating  philosophy  and  applicable  technology  iden- 
tified during  the  initial  RCSDF  design  study  are  summarized  in 
this  section. 

3.1  Emulation  Operating  Philosophy 

The  RCSDF  emulation  operating  philosophy  is  based  on  the  idea 
that  the  facility  provides  services  analogous  to  those  provided 
by  a computer  center.  However,  RCSDF  service  is  different  in 
that  it  concentrates  on  architectural  evaluation  and  development 
rather  than  on  the  normal  program  production. 

An  RCSDF  user  who  wants  to  solve  a class  of  problems  must  first 
precisely  specify  his  problems  using  a requirements  specifica- 
tion language.  He  then  translates  his  requirements  into  HOL 
and  EDL  descriptions.  He  will  also  need  to  specifically  define 
the  user  environment  that  his  system  will  be  encountering,  for 
example:  the  number  of  users  that  will  be  on  his  system,  the 

maximum  (and  average)  data  rate  for  the  I/O  channels,  and  the 
minimum  response  time. 

Using  this  information,  the  hosting  system  will  generate  an 
emulated  version  of  the  hardware  architecture  defined  by  the 
user,  the  software  package  of  his  application  for  the  computer 
system  he  defined,  and  the  scenario  and  test  environment. 

All  of  this  information  will  be  passed  on  to  the  RCSDF  system. 
The  execution  will  be  emulated,  and  various  performance  measures 
be  monitored.  The  performance  measurement  results  will  be  re- 
duced data  given  to  the  user.  After  analysing  the  performance 
data,  the  HOL  and  EDL  descriptions  can  be  modified  and  the 
procedure  repeated  if  necessary,  until  an  optimum  system  design 
is  reached. 
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The  user,  the  host,  and  the  facility  are  each  responsible  to 
each  other.  A simplified  synopsis  of  these  responsibilities  for 
system  design  and  evaluation  is  shown  in  Figures  3-1  and  3-2. 

3.2  RCSDF  Technical  Baseline  Summaries 

The  state-of-the-art  of  technologies  required  by  the  RCSDF  and 
revealed  by  the  baseline  studies  performed  are  summarized  in  this 
section. 

3.2.1  Performance  Measurement  - Performance  measurement  has  two 
distinct  phases:  monitoring  and  data  presentation.  Monitoring 
techniques  include  hardware,  software,  and  hybrid  methods  - 
combinations  of  hardware  and  software.  Data  presentation  in- 
cludes results  which  are  graphic,  tabulated,  or  statistical. 

Because  of  distinctive  RCSDF  properties,  there  are  several 
special  recommendations  for  RCSDF  performance  measurement: 

o Software  (or  firmware,  since  microcode  can  be  used) 
and  hybrid  monitoring  techniques  will  be  necessary 
to  obtain  most  performance  data. 

o Hardware  probes  will  only  be  useful  to  monitor 

performance  data  at  the  component  levels,  e.g.,  channel 
utilization  and  CPU  utilization. 

o An  emulated  clock  system  should  be  used  to  monitor  the 
timing  of  the  emulated  system. 

o The  instruction  time  associated  with  each  instruction 
may  be  calculated  at  the  code  generation  phase  and 
carried  as  a field  in  the  instruction. 

o Data  logging  should  be  provided  between  all  emulated 
modules,  using  hardware  probes  to  tap  interface  lines. 

o The  performance  measures  computation  should  be  done 
in  the  facility. 
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1.  DESCRIPTION  OF  SYSTEM  FUNCTIONAL/PERFORMANCE  REQUIREMENTS  I.  AUTOMATED  SYSTEM  DESIGN  VISIBILITY 

2.  DECOMPOSITION  OF  SYSTEM  REQUIREMENTS  AID 

3.  FUNCTIONAL  MODULE  ALLOCATION  TO  HARDWARE/SOFTWARE  2.  HISTORICAL  REFERENCE  DATA 

4.  FORMULATION  OF  SYSTEM  CONTROL  METHODOLOGY  3.  HOL  DEBUGGING 


3.2.2  Processor  Communication  Techniques/Protocol  - In  order 
to  use  the  RCSDF  concept  to  emulate  a wide  range  of  system 
architectures  and  to  pursue  architectural  research,  the  need 
to  develop  improved  techniques  for  utilizing  and  controlling  a 
multiple  machine  emulating  system  was  indicated. 

Specific  RCSDF  requirements  in  this  area  have  as  yet  to  be 
clearly  specified.  Preliminary  recommendations  about  RCSDF 
processor  communication  techniques  and  protocol  are: 

Topology  and  Interconnect  Implementation  - The  most  effective 
RCSDF  topology  to  implement  is  a star  topology,  one  in  which 
every  device  can  be  directly  interconnected  with  every  other 
device. 

Protocol  Hierarchy  - A protocol  which  makes  the  interface  char- 
acteristics invisible  is  necessary. 

Error  Control  - To  assure  reliable  operations,  retransmission  is 
the  recommended  technique  for  error  control. 

Processor  Communications  Logging  - All  information  moved  using 
the  selected  processor  communications  method  should  be  logged 
to  avoid  erroneous  emulation  results. 

3.2.3  Microprocessor  Network  - The  main  goal  of  the  RCSDF  is  to 
provide  an  emulation  facility  for  new  multi-processor  archi- 
tectures including  architectures  which  contain  microprocessor 
networks.  Examples  of  network  or  multiple-processor  system 
emulations  which  could  conceivably  utilize  a microprocessor 
network  include: 

o Bus-Oriented  Multiprocessor  (e.g.,  Minerva  Multi- 
microprocessor) 
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o Multiport  Multiprocessor  (e.g.,  Univac  1108) 
o Hypercube  Multiprocessor  (e.g.,  Illiac  IV) 
o Multistage  Multiprocessor  Network  (e.g.,  STARAN's  Flip 
Network) 

o Intercomputer  Network  (e.g.,  ARPANET) 

3.2.4  Microprogramming  - Microprogramming  and  microprogrammed 
devices  play  an  important  role  in  RCSDF  development  since  the 
fundamental  concepts  of  emulation  are  based  on  the  use  of  micro- 
programming. Microprogrammed  designs  are  fundamental  for  modern 
emulator  designs. 

The  RCSDF  emulation  research  facility  needs  to  efficiently 
emulate  a wide  variety  of  target  machine  architectures.  To 
accomplish  this,  there  must  be  a "soft  emulation"  machine 
architecture  available  in  the  facility.  This  is  in  sharp  con- 
trast to  the  "hard  emulation"  machine  architectures  (such  as  the 
IBM  360  models)  which  are  designed  to  interpret  only  a small  set 
of  system  architectures.  The  QM-1  is  an  excellent  example  of 
the  soft  emulation  machine  since  it  offers  the  largest  degree  of 
flexibility  of  any  known  machine  for  emulation. 

3.2.5  Operating  System  - The  RCSDF  operating  system  is  defined 
as  the  logic  provided  in  hardware  or  software  necessary  to  main- 
tain control  of  and  provide  user  interface  with  the  RCSDF  re- 
sources. Two  different  operating  system  architectural  structures 
were  considered  for  the  RCSDF  operating  system.  The  first, 
processing  element  control,  assumes  that  the  operating  system 
controls  the  resources.  The  second,  facility  control,  assumes 
resource  control  is  provided  by  user  processes  or  processes 
supplied  by  an  RCSDF  staff  using  interface  standards  enforced 

by  a baseline  operating  system.  It  is  felt  that  either  technique 
could  be  used  to  develop  an  adequate  RCSDF  operating  system. 
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The  advantages  of  the  processing  element  control  method  are  the 
economics  of  being  able  to  utilize  the  existing  resource  control 
capabilities  in  the  current  RCSDF  processing  elements.  The 
facility  control  method  is  recognized  as  having  a greater  risk 
factor,  but  the  gains  which  can  be  realized  from  system  flexi- 
bility and  adaptability  to  various  configurations  are  believed 
to  be  of  significance  in  the  future. 

3.2.6  Distributed  Systems  Organization  - Unfortunately,  the 
phrase  "distributed  processing"  has  become  so  popular  that  almost 
any  computing  complex  containing  more  than  one  processing  element 
capable  of  simultaneous  operation  is  being  called  a distributed 
processing  system.  Nevertheless,  the  study  has  identified  three 
areas  from  which  research  associated  with  "distributed  system" 
can  and  should  impact  the  RCSDF.  The  areas  are: 

o Potential  design  architectures, 
o Potential  architectures  to  be  emulated, 
o Applicable  techniques  for  controlling  emulation. 

RCSDF  relationship  to  distributed  system  organizations  requires 
further  understanding  of: 

o RCSDF  Hardware  Element  Characteristics 
o User  System  Architecture  Spectrum 
o User  Application  Spectrum 
o Emulation  Control  Structure 

3.2.7  Design  Languages  - Design  languages  can  be  categorized 

as:  1)  requirement  specification  languages,  2)  high  order 

languages  (software  design  languages) , and  3)  emulation  design 
languages  (hardware  design  languages) . 

Reoui remen t Specification  Languages  - A cost  effective  develop- 
ment of  systems  necessitates  a carefully  controlled  system 
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requirements  specification  phase.  The  heart  of  any  machine- 
processable  requirement/design  language  is  a competent  data 
base  manager  and  tools  for  design  retention.  ISDOS  (Information 
System  Design  and  Optimization  System)  and  REVS  (Requirements 
Engineering  Validation  System)  come  closest  to  this  ideal. 

Higher  Order  Languages  (HOL)  - A HOL  is  a software  design 
language  that  assumes  the  proportions  similar  or  equivalent  to 
that  represented  by  a COBOL,  JOVIAL,  or  FORTRAN  programming 
language.  Standardizing  HOLS  is  a method  proposed  to  reduce 
software  engineering  costs.  In  1976,  the  DOD  High  Order  Lan- 
guage Working  Group  (HOLWG)  investigated  programming  language 
requirements  and  concluded  that  no  single  existing  standard 
language  satisfied  all  the  language  requirements  even  though  all 
the  capabilities  were  available  in  existing  languages.  The 
group  recommended  that  work  toward  the  production  of  a single 
HOL  should  start  with  an  existing  base  language;  PL/1,  PASCAL, 
and  ALGOL  68  were  recommended.  Current  trends  in  HOL  develop- 
ment indicate  that  additional  capabilities  are  being  included 
that  provide  users  with  high  level  interface  to  operating 
systems  for  resource  and  task  control  facilities. 

Emulation  Design  Languages  - A truly  high  level  language  whose 
sole  purpose  is  emulation  implementation  does  not  exist.  Never- 
theless, Emulation  Design  Language  (EDL)  requirements  can  be 
satisfied  by  some  of  the  Computer  Hardware  Description  Languages 
(CHDLs)  which  allow  computer  hardware  systems  to  be  described  in 
four  levels  of  abstraction  (circuit,  logic,  register-transfer, 
and  processor-memory) . Each  level  of  description  carries  an 
added  amount  of  implementation  detail  than  the  level  preceding 
it.  Typical  languages  in  this  category  are:  AHPL  (based  on 
APL) , CDL  (structured  like  ALGOL) , ISP  (Instruction  Set  Proces- 
sor) , and  PMS  (Processor-Memory-Switch) . 
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4.  RCSDF  Development  Plan 


The  requirements  to  meet  the  overall  objectives  of  the  Reconfig- 
urable  System  Design  Facility  (RCSDF)  are  summarized  herein.  The 
study  team  first  identified  a series  of  additional  concept  form- 
ulation studies  that  would  enable  more  definitive  objectives  to 
be  established  for  the  emulation  facility,  i.e.,  the  RCSDF  por- 
tion of  the  Total  System  Design  Facility  (TSDF) . This  was  fol- 
lowed by  the  establishment  of  six  development  paths  (relatively 
independent  categories  of  development  effort)  for  which  smaller 
work  and  study  tasks  could  be  independently  defined.  Finally, 
the  sets  of  tasks  resulting  from  independent  pursuit  of  the 
developmental  paths  were  combined  into  a single-task  set.  Para- 
graph 4.1  lists  the  required  concept  definition  studies.  Para- 
graph 4.2  shows  the  required  task  work  breakdown  structure  and 
development  plan  schedule,  respectively. 

4.1  Definitive  Study  Tasks 

The  tasks  summarized  below  are  described  in  paragraph  4.1  of 
Volume  II.  They  are  necessary  to  further  clarify  the  objectives 
and  hence  tools  required  to  complete  an  RCSDF  by  1981-1982. 

Emulation  System  Architecture  Study  - The  preparation  of  prelim- 
inary architecture  descriptions  for  the  RCSDF  assuming  use  of 
equipment  already  at  the  Rome  Air  Development  Center,  e.g.,  the 
STARAN,  QM-1,  and  data  manipulator  unit.  Additional  equipment 
identified  by  the  architecture  study  should  include  a large  (109) 
mass  memory  and  a microprocessor  array. 

Emulation  Control  Structure  Study  - The  establishment  of  standard 
component  interface  procedures  for  the  RCSDF.  It  includes  a 
description  of  how  the  standards  are  to  be  implemented  and  en- 
forced in  order  to  regiment  the  control  of  resources . 
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Emulation  Documentation  Structure  Study  - The  definition  of  the 
documents  required  to  coordinate  the  use  of  the  RCSDF  with  the 
concept  of  total  system  design. 

Reguirements/Desian  Language  Procedure  Study  - The  identification 
of  those  languages  which  are  required  for  system  specification, 
design,  and  development  including  methods  of  automating  the  re- 
tention of  a systems  design. 

Uniform  Emulation  Method  Study  - An  analysis  of  existing  emula- 
tion techniques  to  determine  if  common  emulation  procedures  exist 
or  can  be  developed  for  the  RCSDF. 

Emulation  Analysis  Structure  Study  - A description  of  the  tools 
required  to  enable  performance  measurement  and  analysis  to  be 
accomplished  using  the  RCSDF. 

4 . 2 RCSDF  Work  Breakdown  Structure 

Figure  4-7  in  Volume  II  shows  the  RCSDF  Work  Breakdown  Structure 
(WBS) . The  format  agrees  with  MIL-STD-881A,  25  April  1975.  The 
WBS  structure  follows  the  definitions  established  for  electronic 
systems.  The  second  level  definitions  applicable  to  the  RCSDF 
development  are: 

o Prime  mission  equipment 
o System/program  management 
o System  test  and  evaluation 
o Data 
o Training 
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5.  Conclusions 


In  general  the  Sperry  Univac  study  team  has  found  RADC's  concept 
of  Total  System  Design  (TSD) , utilizing  a Reconf igurable  Computer 
System  Design  Facility  (RCSDF)  for  system  design  evaluation,  to 
be  a viable  method  for  reducing  total  system  hardware  and  soft- 
ware costs.  Two  primary  reasons  for  this  conclusion  can  be 
cited.  First,  technology  now  enables  the  development  of  low  cost, 
specialized  hardware  elements,  thus  permitting  selection  of  hard- 
ware elements  tailored  to  high  performance  military  application 
requirement  thereby  ultimately  reducing  the  dependence  on  high 
cost,  complex  software.  The  selection  of  specialized  hardware, 
however,  must  be  delayed  until  the  system  design  requirements  are 
fully  known  and  shown  to  be  reliable  and  viable.  Secondly,  one 
of  the  requirements  of  the  TSD  concept  is  the  need  for  system 
component  interface  standards,  design  and  documentation  standards, 
and  system  performance  and  validation  procedures  to  increase  the 
availability  of  off-the-shelf  hardware  and  software  system  ele- 
ments. Development  of  the  RCSDF  emulation  facility  as  an  integral 
part  of  a total  system  design  methodology  would  promote  both 
inter-  and  intra-system  standardization  as  well  as  more  reliable 
procurement  procedures. 

The  study  team  recognizes  the  technical  risks  involved  in  attempt- 
ing to  provide  a facility  capable  of  emulating  a variety  of  sys- 
tem architectures.  To  reduce  the  risks,  while  promoting  the 
benefits,  Sperry  Univac  suggests  two  alternatives  to  the  four 
year  development  plan  described  in  Section  4 and  shown  in  Figure 
5.1a.  The  alternatives  (Figure  5.1b  and  5.1c)  would  proceed 
under  a phased  development  approach  permitting  risks  to  be  re- 
evaluated and  benefits  identified  before  starting  the  next  phase. 

The  first  alternative  completes  all  TSD  concept  formulation 
studies  before  initiating  implementation/specification  tasks. 
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Figure  5-1.  RCSDF  Development  Plan  Time  Lines 


It  retains  the  primary  objective  to  develop  a general  purpose 
emulation  facility,  i.e.,  an  RCSDF . The  advantage  would  be  a 
reduction  in  technical  uncertainty  and  hence  elimination  of 
potential  cost  increases.  The  disadvantage  is  the  increase  in 
time  before  total  system  design  benefits  can  be  achieved. 

The  second  alternative  would  narrow  the  scope  of  the  initial 
RCSDF  development  by  concentrating  on  a single  case  study  thus 
reducing  its  dependency  upon  the  evolving  total  system  design 
methodology.  The  advantages  of  this  alternative  are  a reduction 
in  time  required  to  demonstrate  benefits  plus  an  increase  in 
working  knowledge  of  the  problems  which  remain.  The  disadvantage 
is  the  potential  higher  program  cost  associated  with  hardware  and 
software  development  efforts  failing  to  meet  the  needs  of  other 
case  studies/applications. 

The  Sperry  Univac  study  team  has  concluded  that  the  tasks  iden- 
tified in  the  contracted  development  plan  (Section  4),  tailored 
to  meet  specific  case  study  objectives  (alternative  2 - Figure 
5.1c) , would  ultimately  provide  RADC  with  the  most  timely 
benefits  at  a lower  risk  and  cost. 
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